Verifying consistency among device configurations based on comparing configuration files

ABSTRACT

A scalable comparison structure and methodology is provided that is suitable for comparing the configuration of devices in an efficient manner. In the configuration files, section delimiters are defined to identify the sections of the files within which the select data content is located, and differences in the sections are identified based on the select data content within the section. Thereafter, comparisons and reports are based on these unique content sections. Groups of devices are optionally defined, and different sets of select data content can be compared based on these groups. The result of the comparison may be presented in multiple hierarchical forms, including an identification of which configuration files are different from each other, and an identification of the differences among the unique content in these configuration files.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/176,317, entitled “VERIFYING DATA CONSISTENCY AMONG MULTIPLESTRUCTURED FILES,” filed Jul. 18, 2008, which claims the benefit of U.S.Provisional Patent Application 60/968,013, filed 24 Aug. 2008, both ofwhich are herein incorporated by reference in their entirety.

FIELD

This invention relates to the field of data processing, and inparticular to a method and system for comparing the content of multiplefiles. Such a method and system is particularly well suited forcomparing configuration files that are associated with devices on acommunications network, to verify data consistency among the devices.

BACKGROUND AND SUMMARY

In many systems, common data is expected to be associated with multipleelements of the system. In a conventional database system, for example,individual data sets would include references to the particular items ofcommon data, so that when any common data item is changed, the change isautomatically reflected in each of the data sets that reference thiscommon data item. In a distributed system, common data can be similarlyreferenced by each remote element of the system, but such an approachwould be extremely vulnerable to a single point of failure that affectsaccess to the common data by the remote elements.

To assure reliability in a distributed system, a copy of the common datais generally maintained at each remote element of the system. Suchdistribution, however, introduces the possibility of different versionsof the common data being present at different remote elements.Additionally, in many cases, the remote elements of a distributed systemare not homogeneous, per se, and the form of the common data atdifferent elements of a distributed system may often differ, increasingthe likelihood of differences appearing at each element. In like manner,not all remote elements will necessarily share the same items of commondata, and some elements may purposely be designed to use locally defineditems in lieu of some of the items of common data.

A communication system comprising a network of devices is a particularexample of a distributed system of non-homogenous elements that accessdata items that are expected to be common among at least a subset of theelements. For example, if TCP services are to be provided on a givennetwork, all of the files that are used to configure the routers of thenetwork would be expected to include a “TCP Services” entry. Thisparticular entry may differ in format among different router vendors,and may appear at different locations within each particularconfiguration file.

For ease of reference and understanding, the collection of data at aremote element of a distributed system is herein defined to be locatedin a ‘file’, although one of skill in the art will recognize that thisterm refers to the logical arrangement of data, and such ‘files’ may bemaintained in a variety of physical forms, including, for example, adata collection on multiple devices of the remote element. In likemanner, the aforementioned term ‘distributed system’ refers to a logicaldistribution of elements, independent of the physical arrangement ofsuch elements. Using this terminology, in a distributed systemcomprising multiple elements, each element possesses one or more filesthat contain data items, some of which data items are assumed to becommon among all or some of the elements.

Conventional file comparators are generally unsuitable for comparing alarge number of files. A typical file comparator compares two files andhighlights the differences between the files based on a comparison ofthe text. Some file comparators are able to compare three files, usingdifferent methods of highlighting for each of the types of differences.For example, with three files, A, B, C, there are six different types ofdifferences among the files: in A, but not in B or C; in A and B, butnot in C; not in A or C, but in B; and so on. Comparing four or morefiles quickly becomes infeasible using conventional text basedcomparators.

In like manner, conventional file comparators are generally unsuitablefor comparing files that have many non-common data items, becausedifferences among the items that are expected to be common are noteasily distinguishable from the different non-common data items. And, ifthe common data items are different only in form, such differences arealso not distinguishable from the substantive differences among thecommon data items.

It would be advantageous to provide a means for comparing particulardata items or sets of data items in multiple files to identifydifferences among the files. It would also be advantageous to provide auser interface that allows a user to formulate the comparison taskeasily and efficiently. It would also be advantageous to provide anoutput scheme that presents the detected differences in a substantivelymeaningful and understandable form.

These advantages, and others, can be realized by providing a scalablecomparison structure and methodology that is suitable for comparingselect data content in hundreds or thousands of files in an efficientmanner. Section delimiters are defined to identify the sections of thefiles within which the select data content is located, and sets ofunique sections are identified based on the select data content withinthe section. Thereafter, comparisons and reports are based on theseunique content sections. If multiple files include a common set of data,a single unique content section is used to represent these multiplefiles. File groups are optionally defined, and different sets of selectdata content can be compared based on these file groups. The result ofthe comparison is presented in multiple hierarchical forms, including anidentification of which files are different from each other, and anidentification of the differences among the unique content segments.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is explained in further detail, and by way of example,with reference to the accompanying drawings wherein:

FIG. 1 illustrates an example flow diagram for creating an examplestructured comparator in accordance with this invention;

FIG. 2A-2B illustrates an example comparison of a select section amongthree devices using the techniques of this invention;

FIGS. 3A-3C illustrate an example set of XML-like structures thatfacilitate defining a network comparison task;

FIG. 4 illustrates an example block diagram of a structured comparatorin accordance with this invention; and

FIGS. 5A-5F illustrate an example set of outputs of the examplestructured comparator of this invention.

Throughout the drawings, the same reference numerals indicate similar orcorresponding features or functions. The drawings are included forillustrative purposes and are not intended to limit the scope of theinvention.

DETAILED DESCRIPTION

In the following description, for purposes of explanation rather thanlimitation, specific details are set forth such as the particulararchitecture, interfaces, techniques, etc., in order to provide athorough understanding of the concepts of the invention. However, itwill be apparent to those skilled in the art that the present inventionmay be practiced in other embodiments, which depart from these specificdetails. In like manner, the text of this description is directed to theexample embodiments as illustrated in the Figures, and is not intendedto limit the claimed invention beyond the limits expressly included inthe claims. For purposes of simplicity and clarity, detaileddescriptions of well-known devices, circuits, and methods are omitted soas not to obscure the description of the present invention withunnecessary detail.

This invention is premised on the observation that data files in adistributed system are typically well structured, and a file comparatorthat takes advantage of such structure will be substantially moreefficient and effective than a conventional general purpose filecomparator. This invention is also premised on the observation that thecomparison of data files in a distributed system is often a targetedsearch for differences among select data items that are expected to becommon among multiple files. One of skill in the art will recognize,however, that although the techniques presented herein are particularlywell suited for these situations, these techniques are not necessarilylimited to distributed systems, well structured files, or data itemsthat are expected to be common.

The invention is presented using the paradigm of a communication systemcomprising a network of devices, each device being configured foroperation on the network based on data items in a correspondingconfiguration file. Device configuration files generally contain dataitems that are unique to the particular device, and data items that arecommon to particular sets of devices, including the set of all deviceson the network, or all similar device types on the network. Although theapplication of the principles of this invention are particularly wellsuited for comparing network configuration files, one of skill in theart will recognize that this invention is not limited to this particularapplication. In like manner, network configuration data may haveparticular relationships, limits, and constraints, whereas suchcharacteristics are not, per se, characteristics of this invention.

Network devices typically perform a variety of tasks or functions, eachof which generally having one or more parameters that are set to effectdifferent aspects of the task or function. To determine which parametersets are being initialized by each entry in a device's configurationfile, the configuration file is often structured so as to identify theparticular task or function, followed by an identification and value(s)for each parameter set that is to be modified, and concluded with anidentifier of the end of the list of parameter sets. In some cases,these sets of function-parameter(s)-end sets are nested within otherfunction-parameter(s)-end sets in a hierarchical manner. In other cases,the parameter sets for a particular task or function are eachindependently specified, wherein, for example, the identification of theparticular task or function is included at the beginning of eachconfiguration phrase, followed by an identifier and value(s) of theparameter set, and an end-of-line or other symbol indicating the end ofthe phrase. Generally, each of these independent parameter sets appearcontiguously in the configuration file, however the physical location ofeach parameter set is immaterial to the collection of such parametersets that form a logical ‘section’ of the configuration file associatedwith the particular task or function.

For example, in a typical communications network, most devices willinclude SNMP (Simple Network Management Protocol) capabilities thatallow a remote monitoring system to query each device regarding itscurrent status. Configuration information for SNMP services includes,for example, an identification of the SNMP community accessstring/password, an identification of one or more SNMP groups and theirviewing rights to data within the device, the version(s) of SNMPsupported by the device, and so on. To identify SNMP configurationinformation, the configuration phrase is initiated with the SNMPidentifier, followed by the parameter set identifier, followed by theparameter value(s), as in:

-   -   snmp-server community string view view-name ro.        In this example, “snmp-server” identifies the phrase as being an        SNMP configuration entry; “community” identifies the phrase as        defining access control for a community; string is the        particular value of the access control password; “view”        identifies the phrase as defining which views (types) of SNMP        data are controlled by this access control; view-name is the        particular view for which access is granted; and “ro” identifies        the access as read-only.

In the above example, an “SNMP” section of a file can be defined as thecollection of all configuration phrases that begin with “snmp-server”,regardless of where these phrases appear in the configuration file. Inlike manner a section can be defined as the collection of all theconfiguration files that begin with “snmp-server” except thoseassociated with particular parameters that are of no interest to theuser. Similarly, a section can be defined as the collection of theconfiguration files that begin with “snmp-server” and are associatedwith the particular parameters that are of interest to the user. Forexample, for assuring proper SNMP monitoring within a network, thecommunity password should generally be common among all of the monitoreddevice, and thus comparing this parameter among devices would be ofinterest to a network manager. Conversely, a configuration phrase thatprovides a device identifier or device location would be expected todiffer among the devices, and would not be of interest for comparisonpurposes. One of skill in the art will recognize that any of a varietyof rules can be provided to include or exclude particular types ofconfiguration phrases within the defined section to facilitatemeaningful and efficient comparisons among device configuration files.

FIG. 1 illustrates an example flow diagram for comparing elements of adefined section from among multiple files. At 110, the elements formingthe section that is to be compared among the files are defined. Asdiscussed above, any of a variety of identifiers can be used to includeor exclude elements of a file for selection as members of the section.For example, {“snmp-server” but not “device-id”} can be used as asection selection identifier to select all configuration phrases thatinclude “snmp-server” except those that also include “device-id”;{“snmp-server” and “community”} can be used as a section selectionidentifier to select all configuration phrases that include both“snmp-server” and “community”. In a preferred embodiment, a structuredform for defining sections is used to reduce the likelihood of erroneousselections or non-selections, as detailed further below.

At 120, a set of unique content sections is initialized, typically toeither a null set or a default set. As detailed below, the section ofeach file will be classified as being equivalent to one of the sectionsof this (expandable) set of unique content sections, based on theparticular content of the section of the file. The set of unique contentsections can be initialized, for example, to include a section thatcontains the expected content of the section in all or most of thefiles. In the example of a network configuration comparison system, thedefault set could be a defined section that includes the expectedconfiguration of each of the parameter sets of interest. In like manner,the set of unique content sections can include a set of defined sectionsthat include different allowable configurations of the parameter sets ofinterest.

The loop 130-180 processes each file to compare the content of thedefined section among the multiple files. At 140, the section of thecurrent file is extracted; as noted above, this (logical) section can beindependent of the physical arrangement of elements in the file, thesection being defined by the one or more section selection identifiers,at 110.

At 150, the section extracted from the current file is compared to eachsection of the set of unique content sections until a match is found, ifany. In most cases, this comparison is performed independent of theorder in which the content appears in the section. However, in apreferred embodiment, a difference in the order of particular elementsof the section can be specified as constituting a non-match between thesections.

The method of comparison and criteria used for declaring a match can becustomized, depending upon the nature of the comparison task. Absent anyinformation to the contrary, a literal match of each parameter value isrequired to declare a match. In systems designed for a particularcomparison application, context-based comparisons can be used, whereinknowledge of the particular use or function of a given parameter set canprovide for a more reasoned match determination, as compared torequiring a literal match. In a customizable embodiment, the user may beprovided the option of defining criteria for comparing particularparameter values, such as giving a range of tolerances (e.g. +/−10%) fordetermining matches among numeric parameters, allowing synonyms for textparameters, and so on. In a fully controllable comparison system, theuser may be provided the option of providing a software function thatreceives as input the content of each section to be compared, andreturns a ‘match’ or ‘no-match’ determination, thereby providingunlimited flexibility in defining the method and criteria for performingthis comparison. In like manner, the user may be provided the option todefine a software function that receives as input a particular parameterset and its value(s) for each of the two sections to be compared, andreturn a ‘match’ or ‘no-match’ determination for that parameter set.These and other techniques for providing comparison techniques beyondliteral matching will be evident to one of skill in the art in view ofthis disclosure.

If, at 155, a match is found between the section of the current file andone of the unique content sections, an association is establishedbetween that unique content section and the current file, at 170. If, at155, a match is not found, the content of the section of the currentfile must be unique, and is therefore added to the set of unique contentsections, to which sections of subsequent files will be compared, at150. An association is also established between this newly added uniquecontent section and the current file, at 170.

After all of the sections of the files are compared and all files arecorrespondingly associated with a unique content section, any of avariety of reports can be generated based on the unique identifiersand/or the association of files to these unique identifiers, at 190, asdetailed further below.

FIGS. 2A and 2B illustrate an example comparison of an SNMPconfiguration among three devices D1, D2, D3 using the techniques ofthis invention.

In FIG. 2A, each of the devices D1, D2, and D3 are illustrated as havingan SNMP configuration section, the definition of the elements of thisconfiguration section being defined by one or more section selectionidentifiers, as discussed above. The extraction of the defined SNMPconfiguration section from device D1 provides elements X, Y, and Z; theextraction from D2 provides elements of W, Y, and Z; and the extractionfrom D3 provides elements X, Y, and Z.

As illustrated in FIG. 2B, the extraction of the SNMP configuration fromdevices D1 and D2 will produce two unique content sections. The firstunique section includes elements X, Y, and Z; the second unique sectionincludes elements W, Y, and Z. When the contents of the extractedconfiguration from device D3 is compared to the first unique section, amatch is determined, and device D3 is associated with the first uniquesection.

Of particular note, once a match to a unique content segment isdetermined, the configuration of D3 does not need to be compared to theconfiguration of any other section, because the unique content sectionsare defined/created to be unique. Thus, for example, D3 does not need tobe compared with D1 or D2, because being associated with a uniquecontent section automatically determines D3's status relative to allother devices: it's configuration matches all devices that areassociated with the first unique content section, and is different fromall devices that are associated with any of the other unique contentsections. Although this savings may not appear significant in thisthree-device example, consider the savings realized when a hundredthdevice is found to match a unique content section. In a conventionalcomparison system, the hundredth device would need to be compared witheach and every one of the first ninety-nine devices; in this invention,it need only be compared to the unique content sections, and only untila match is found. As will be evident to one of skill in the art, thistechnique easily allows for the comparison of thousands of devices,because, if the defined sections for comparison are expected togenerally contain the same information, the number of unique contentsections will grow much more slowly than the number of devices beingcompared.

Given the above described technique that allows for an efficientcomparison of hundreds or thousands of files, a number of enhancementscan be included to facilitate the efficient collection of data andsubsequent reporting of the results of the comparisons. Suchenhancements may be of a general nature, while others may be specific tothe particular application for which the comparison system is designed,such as the example comparison system of this disclosure that isdesigned for comparing network configuration data.

Most network comparison tasks are targeted to particular devices ordevice types, and it would be advantageous to provide a scheme forefficiently identifying which devices/files to include or exclude fromthe comparison process of FIG. 1. For example, a comparison may betargeted to only the routers on the network, or only the firewalls onthe network, and so on. Similarly, the comparison may be targeted toonly the routers of a particular class, or at a particular location, andso on.

It is often desirable to compare different sections of configurationdata for different types or classes of devices, or for differentcomparison tasks applied to the same device or device class. That is,for example, a comparison task may include a comparison of the SNMPconfiguration among all routers, a comparison of TCP configuration amongrouters of a first and second class of routers, a comparison ofAnti-Spoofing configurations among routers of the first class and athird class, and so on.

To allow for a flexible and efficient means for managing targetedcomparison tasks among multiple types of devices, the concepts of“Device Group” and “Device Group Class” are used to define membership intest/comparison groups. A device group is, as the name implies, anidentified group of devices; a device group class is a set of devicegroups for which the same set of comparisons is to be applied. In apreferred embodiment, a user identifies each defined device group byname, and each defined compare-section by name. Then, the device groupclass is defined along the lines of: “For groups A, B, and D, testsections S1 and S3.” In this definition, each test section is applied toeach group independently. Different device group classes can be defined,and any group or section may be included in multiple device groupclasses.

FIGS. 3A-3C illustrates an example specification of sections, groups,and classes using an XML-like format.

FIG. 3A illustrates an example XML-like specification of sections thatare to be available for comparison if included in a device group class.In this example specification, three comparison sections are defined:“SNMP” 310, “ISIS” 315, and “Tunnels” 320. As discussed above, thedefinition of each section includes a specification for identifying abeginning (StartRegEx) and end (EndRegEx) of elements that areassociated with the particular section. In this example, elements of theSNMP section begin with “snmp-server”; elements of the ISIS sectionbegin with “router isis core”; and elements of the Tunnels section beginwith “interface Tunnel”. The end of each example element is identifiedby a blank line.

If no further entries are specified, as in the ISIS section definition315, all elements that are consistent with the section beginning and endspecification will be included in the comparison. Alternatively, thesection definition may specify particular elements to include orexclude. In the SNMP section 310, only elements that include “community”or “host” will be included, except those that include “host” and“192.168.50.254”.

FIG. 3B illustrates an example XML-like specification of device groupsthat are to be available for comparison if included in a device groupclass. In this example, three device groups are defined: “T01 Routers”330, “Px Routers” 335, and “PEx Routers” 340. The definition of eachdevice group specifies which devices to include, and, from within thatinclusion, which devices to exclude. For example, the group T01 Routers330 will include all devices with a hostname that ends with “T01”,except those that end with “XT01”.

FIG. 3C illustrates an example XML-like specification for device groupclasses. As discussed above, each device group class serves to identifywhich devices are to have which sections compared. In this example, twodevice group classes are defined: “Tier-1 Configuration” 350 and “Tier-2Configuration” 360. The Tier-1 Configuration 350 specifies that devicesin groups T01 Routers 351 and Px Routers 352 are to be ‘tested’ bycomparing sections SNMP 353 and Tunnels 354 in the configuration filefor each device. The Tier-2 Configuration 360 specifies that devices ingroup PEx Routers are to be tested by comparing sections ISIS andTunnels.

These device group classes are processed to identify which deviceconfiguration files to compare, and which set of sections in each fileneeds to be compared. As detailed above, each section comparison isperformed by comparing the section of each file to a set of uniquecontent sections, and an association is defined between the file andeach of its unique content sections. Thereafter, the results of thecomparison tasks as defined by the device group classes are presentedbased on these associations to the unique content sections.

FIG. 4 illustrates an example block diagram of a network configurationverification system in accordance with this invention.

A test compiler 410 is configured to process section definitions 401,device group definitions 402, and device group class definitions 403 toprovide a set of comparison tasks for the section extractor andcomparator 420 to perform. As noted above, the device group and devicegroup classes are optional, but have been found to be particularlyeffective for defining well targeted comparisons that minimize thereporting of immaterial or extraneous differences.

The section extractor and comparator 420 extracts the pertinent sectionsfrom the configuration file 430 of each of the devices beingtested/compared. A set of unique content sections 440 is created bycomparing each extracted section with the current set of unique contentsections for the particular section being compared, and adding theextracted section to the set only if it does not match one of theexisting unique content sections. When a match is found, or when theextracted section of a file is added to the set of unique contentsections, the file is associated 450 with the matching/added uniquecontent section.

Given the set of file-section associations for all of the files beingcompared, and the sets of unique content sections for each associatedsection, a report generator 460 presents the results of the comparisontasks to a user, typically via an interactive interface 470, as detailedbelow.

Any of a number of reports may be provided based on the unique sectionsthat are included in each file of each group. Such reports includereports that provide summary information, such as the number of filesassociated with each of the most popular unique content sections, aswell as reports that include verifications, such as an identification ofeach file that differs from a unique content section that represents anexpected/required configuration, as well as reports that identify howeach device in each group is configured for each of the tested sections.Of particular note, in a preferred embodiment, only the particularsections of the devices within each device group class are included inthe reports. That is, for example, two devices may have differences in aparticular section, but only if the two devices appear in a defineddevice group class, and that particular section is included in thisdefined group class, will the differences be reported. In this manner,the amount of extraneous and/or immaterial information that is includedin the comparison reports is minimized.

The following paragraphs describe some preferred output reports,although one of skill in the art will recognize that other reports thatare based on the determined unique content sections, and the associationbetween each device configuration file and these determined uniquecontent sections can be created as well.

FIG. 5A illustrates an example verification summary report thatidentifies the results of the comparison of the sections specified inthe example device group classes of FIG. 3C. In this example, the reportis partitioned by device groups (T01 Routers, Px Routers, PEx Routers).For each device group, each device group class to which the device groupbelongs is listed. In this example, each device group only appears inone device group class. For each device group class, the tested sectionsare listed with an indication of whether the section in the devices ofthe device group exhibited any differences.

Within the T01 Routers group, the SNMP section differed among therouters in the group; the “N/A” entry under the Differences columnindicates that no Tunnels were found in the group of T01 Routers. Withinthe Px Routers group, the SNMP section differed among the routers in thegroup, but the Tunnel section of all of the routers in the group showedno differences. Within the PEx Routers group, both the ISIS and Tunnelsections exhibited differences among the devices in that group.

The Details column provides a hyper-link for each section to allow auser to “drill-down” to obtain further details. For example, selectingthe <link1> entry in the T01 Routers SNMP section may provide details asillustrated in FIG. 5B.

In FIG. 5B, the SNMP section for the T01 Routers indicates that threeunique content segments (T01Routers.SNMP(1), T01Routers.SNMP(2),T01Routers.SNMP(3)) were discovered among the devices in the T01 Routersgroup. The first unique content segment T01Routers.SNMP(1) is present ineach of the listed devices NYT01, CAT01, SFT01, IAT01, and MIT01, andabsent from the devices NJT01, LAT01, and CHT01. The devices in whichthe second and third content segments are present and absent aresimilarly listed. As indicated by the underlined section names, theseare hyperlinks for obtaining the details of each of the unique contentsegments.

In addition to allowing a user to obtain details by drilling down, thepreferred system also provides a consolidated view at more detail thanthat of FIG. 5A. FIG. 5C illustrates an example consolidated view thatuses indentation to display the hierarchical nature of the sectioncomparisons.

FIG. 5C presents the comparison results partitioned in the hierarchicalorder of Device Group Class, Device Group, and Section. The display ofthe section data is as discussed with regard to FIG. 5B. Note that theunique content sections are presented as a function of the device group.That is, one or more unique content sections identified in the SNMPsection of the T01 Routers may match one or more of the unique contentsections identified in the Px Routers device group, but the comparisons,and hence the unique content sections, are specific to each devicegroup.

FIG. 5D illustrates another example summary report, also organized bythe hierarchical order of Device Group Class, Device Group, and Section.In this presentation, the number of unique content segments within eachconfiguration section of each device group within each device groupclass is identified. If only one unique content section for a givensection is found, then all of the devices in this section must sharethis common content, and the number of these identically configureddevices (for this section) is displayed.

The underlined entries in FIG. 5D indicate hyper-links that provideadditional details. Selecting a device group name or section nameproduces a display of the defined characteristics (FIGS. 3A and 3B) ofthe section or group. Selecting the number (of devices) within a devicegroup produces a display of all of the devices that satisfied thedefined characteristics of the group. That is, for example selecting the(8) entry for the T01 Routers group provides a display of the eightrouters having a host name that ends in “T01” as specified in FIG. 3B.

Selecting a particular Configuration Section Type in FIG. 5D providesthe example display of FIG. 5E. In FIG. 5E, the specification of theselected section is presented in a more readable form than the inputformat for this specification in FIG. 3A, and details of each of theunique content sections that match this specification are illustrated.In this example, the two unique content sections differ in the contentof the “net” parameter, and the absence of a “mpls traffic-engrouter-id” entry in the second unique content section.

To facilitate the identification of the specific difference among theunique content segments, FIG. 5F illustrates an example detailed displayof the particular content found in the sections of all the devices inthe group. In this example, the entries are listed in alphabeticalorder, although a user-specified order is also provided. The two uniquecontent ISIS sections identified in FIG. 5E form two columns in thispresentation; if more unique content sections were found, additionalcolumns would be displayed, one for each unique content section.

In the example of FIG. 5F, the entry in each unique content sectioncolumn indicates the order in which the given entry appears in thesection, assuming that the order of statements is relevant to thecomparison. If the order of the statements is immaterial to thecomparison tasks, these numerical entries are replaced by a ‘check’ or‘x’ symbol, indicating that the entry is present somewhere in thesection.

Of particular note, each of the various displays of FIGS. 5A-5F iscreated based on the unique content sections and the associations of thedevice configuration files to these unique content sections. Also ofparticular note, as compared to an exhaustive comparison of eachconfiguration file with each and every other configuration file, noinformation is lost via the use of these unique content sections andassociations for the parameters of interest in each section.

The foregoing merely illustrates the principles of the invention. Itwill thus be appreciated that those skilled in the art will be able todevise various arrangements which, although not explicitly described orshown herein, embody the principles of the invention and are thus withinthe spirit and scope of the following claims.

In interpreting these claims, it should be understood that:

a) the word “comprising” does not exclude the presence of other elementsor acts than those listed in a given claim;

b) the word “a” or “an” preceding an element does not exclude thepresence of a plurality of such elements;

c) any reference signs in the claims do not limit their scope;

d) several “means” may be represented by the same item or hardware orsoftware implemented structure or function;

e) each of the disclosed elements may be comprised of hardware portions(e.g., including discrete and integrated electronic circuitry), softwareportions (e.g., computer programming), and any combination thereof;

f) hardware portions may be comprised of one or both of analog anddigital portions;

g) any of the disclosed devices or portions thereof may be combinedtogether or separated into further portions unless specifically statedotherwise;

h) no specific sequence of acts is intended to be required unlessspecifically indicated; and

i) the term “plurality of” an element includes two or more of theclaimed element, and does not imply any particular range of number ofelements; that is, a plurality of elements can be as few as twoelements, and can include an immeasurable number of elements.

1. A method for comparing a plurality of files, comprising: identifyinga section of each file of the plurality of files based on one or moresection selection identifiers, defining a set of unique content sectionsbased on content of the sections of the plurality of files, andproviding a display of information based on the set of unique contentsections.
 2. The method of claim 1, wherein identifying the section ofeach file includes defining parameters that identify a start and end ofone or more elements of the section in each file.
 3. The method of claim1, wherein defining the set of unique content sections includes:comparing the content of the section of each file with each uniquecontent section of the set of unique content sections, and if thecontent of the section does not correspond to any of the current set ofunique content sections, adding the section to the set of unique contentsections.
 4. The method of claim 3, wherein comparing the content of thesections of each file with each unique content section is performedwithout regard to an order of the content.
 5. The method of claim 1,wherein the plurality of files include files that identifyconfigurations of devices of a network.
 6. The method of claim 5,wherein the plurality of files correspond to a defined group of devices.7. The method of claim 1, wherein the display of information is based ona count of the files that include sections corresponding to at least oneof the set of unique content sections.
 8. The method of claim 1, whereinthe display of information is based on a count of unique contentsections in the set of unique content sections.
 9. The method of claim1, wherein the display of information includes an identification of thefiles that include sections corresponding to at least one of the set ofunique content sections.